Skip to main content

Helm Chart Configuration & Dependencies

This guide provides a structured approach to deploying Exivity on Kubernetes using Helm, including all required dependencies and configuration steps.

Third-party dependencies

The Exivity Helm chart deploys the Exivity application and can optionally deploy third-party middleware dependencies such as PostgreSQL and RabbitMQ through chart dependencies. The embedded dependencies are based on the Bitnami PostgreSQL Helm chart and Bitnami RabbitMQ Helm chart, currently consumed through the Exivity-hosted Bitnami chart mirror for compatibility. Exivity relies on these products, but you remain responsible for operating, securing, backing up, monitoring, upgrading, and supporting the third-party platforms used in your Kubernetes environment.

Key Configuration Options​

Below are the most important Helm values to consider for a typical deployment. For the full list and advanced options, always refer to the values.yaml.

ValueDescriptionExample
nameOverrideOverride deployment name (useful for multiple instances).nameOverride: "exivity-prod"
licenceExivity license key. Use demo for evaluation, or request a trial/production key.licence: "demo"
secret.appKey / secret.jwtSecretApplication and JWT secrets. Set for production (auto-generated if empty).secret.appKey: <your-key>
💾 storage.storageClassStorage class for all persistent volumes. For multi-node clusters it must support RWX; for single-node clusters it only needs to support your chosen access mode (often RWO).storage.storageClass: <your-storage-class>
💾 storage.permissions.enabledEnable init container to fix volume ownership, useful for NFS.storage.permissions.enabled: true
🚦 ingress.enabledEnable/disable ingress.ingress.enabled: true
🚦 ingress.hostHostname for ingress.ingress.host: exivity.example.com
🚦 ingress.trustedProxyTrusted proxy IPs for load balancers such as Traefik.ingress.trustedProxy: "10.244.0.0/16"
🐘 postgresql.enabledDeploy embedded PostgreSQL or use external PostgreSQL.postgresql.enabled: false
🐘 postgresql.hostHostname for external PostgreSQL.postgresql.host: db.example.com
🐇 rabbitmq.enabledDeploy embedded RabbitMQ or use external RabbitMQ.rabbitmq.enabled: false
🐇 rabbitmq.hostHostname for external RabbitMQ.rabbitmq.host: mq.example.com
📦 service.tagImage tag for Exivity service images. If empty, the chart default is used.service.tag: "3.38.4"

Prerequisites​

  • Kubernetes cluster (cloud or on-premises)
  • kubectl and helm installed
  • Sufficient cluster resources (see System requirements)
  • Shared storage for Exivity volumes. For multi-node clusters this must be RWX-capable (such as NFSv4 or a CSI-backed ReadWriteMany provider). For single-node clusters, RWX is not required and a local-path or HostPath RWO provisioner is sufficient (see below).

1. Shared Storage Setup​

Exivity stores logs, configuration, and pipeline data on shared persistent volumes. The required access mode depends on cluster size:

  • Multi-node clusters require ReadWriteMany (RWX). NFSv4 is supported because it provides file locking, and CSI-backed providers such as Longhorn can be used when they support RWX volumes. When NFS is used, the recommended in-cluster option is the NFS Ganesha server and external provisioner (nfs-server-provisioner Helm chart), which serves NFSv4 with file locking.
  • Single-node clusters do not require RWX. Set storage.sharedVolumeAccessMode: ReadWriteOnce and use any local-path or HostPath provisioner (for example K3s' built-in local-path storage class, or local-path-provisioner). RWX storage is only needed if you plan to add more nodes later.

Install NFS Server Provisioner (example)​

If your multi-node cluster does not already have a managed NFS solution, you can deploy the NFS Ganesha server and external provisioner in-cluster using Helm. This is a third-party component that you operate:

helm repo add nfs-ganesha-server-and-external-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server nfs-ganesha-server-and-external-provisioner/nfs-server-provisioner \
    --namespace nfs-server \
    --create-namespace \
    --wait \
    --set persistence.enabled=true \
    --set persistence.size=5Gi \
    --set storageClass.name=<your-storage-class-name> \
    --set storageClass.allowVolumeExpansion=true \
    --set 'storageClass.mountOptions[0]=nfsvers=4.2' \
    --set 'storageClass.mountOptions[1]=rsize=4096' \
    --set 'storageClass.mountOptions[2]=wsize=4096' \
    --set 'storageClass.mountOptions[3]=hard' \
    --set 'storageClass.mountOptions[4]=retrans=3' \
    --set 'storageClass.mountOptions[5]=proto=tcp' \
    --set 'storageClass.mountOptions[6]=noatime' \
    --set 'storageClass.mountOptions[7]=nodiratime'

Note: Replace <your-storage-class-name> with a descriptive name (e.g., exivity-nfs, shared-storage). You'll use this name when installing Exivity.

Note: Ensure your NFS server and Kubernetes storage class are configured for NFSv4. For cloud providers, see their documentation for managed NFS solutions (e.g., GKE Filestore, Azure Files, AWS EFS).

2. Add the Exivity Helm Repository​

helm repo add exivity https://charts.exivity.com
helm repo update

3. Install the Exivity Helm Chart​

Replace <namespace> and <release-name> as needed. Set the storage class to your RWX-capable storage class:

helm upgrade --install <release-name> exivity/exivity \
    --namespace <namespace> \
    --create-namespace \
    --wait \
    --set storage.storageClass=<your-storage-class-name>

Important: Replace <your-storage-class-name> with the actual name of your ReadWriteMany (RWX) storage class.

4. Helm Chart Configuration​

5. NFS Readiness Probe Improvement​

info

Note: As of Exivity v3.29.3, the NFS readiness probe has been replaced with a more reliable solution, improving detection of NFS connectivity issues and overall system stability. See release notes for details.

Important: PostgreSQL for Production​

caution

Production Recommendation: Use a Dedicated PostgreSQL Server

  • The embedded Bitnami PostgreSQL chart is included for convenience and is suitable for quick start, testing, and some production scenarios.
  • However, for most production environments, we recommend using a dedicated PostgreSQL server—either a managed database from your cloud provider or a self-hosted, production-grade PostgreSQL instance—for improved scalability, backup, and high availability.
  • If you choose to use the embedded Bitnami PostgreSQL chart in production, ensure you have appropriate backup and monitoring strategies in place.
  • The embedded PostgreSQL and RabbitMQ dependencies currently use the Exivity-hosted Bitnami chart repository and bitnamilegacy images as a temporary compatibility measure following the Bitnami container catalog changes on September 29, 2025. The Bitnami RabbitMQ chart in particular relies on an unsupported image that will not receive updates or security patches. Site-local in-cluster RabbitMQ remains the recommended default for Exivity, but for production, run RabbitMQ outside the Exivity chart using the RabbitMQ Cluster Operator (preferred) or a managed RabbitMQ, and connect Exivity to it through the external rabbitmq.host/rabbitmq.port/rabbitmq.vhost/rabbitmq.secure values. See the Best practices RabbitMQ section for the full recommendation.
  • PostgreSQL, RabbitMQ, Longhorn, NFS, ingress controllers, and monitoring stacks are third-party products. Exivity relies on compatible services but does not take operational responsibility for those products in self-managed environments.

To use an external database, set postgresql.enabled: false and configure postgresql.host, postgresql.port, and authentication values accordingly.

6. Longhorn Storage Support​

info

Exivity supports alternative CSI storage providers such as Longhorn. For production architecture recommendations, see Exivity Kubernetes best practices.

Using Longhorn​

  • Install Longhorn on your cluster:
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace

  • Reference: Longhorn Helm install docs

  • Set the Exivity Helm value storage.storageClass to your Longhorn storage class (usually longhorn).

  • Important: When using Longhorn, you must explicitly set the PVC sizes for each service in your values.yaml file. Unlike NFS, Longhorn strictly enforces the defined PVC sizes.

storage:
  storageClass: longhorn
  pvcSizes:
    log:
      chronos: 5Gi
      edify: 5Gi
      executor: 5Gi
      glass: 5Gi
      griffon: 5Gi
      horizon: 5Gi
      pigeon: 5Gi
      proximityApi: 5Gi
      proximityCli: 5Gi
      transcript: 5Gi
      use: 5Gi
    config:
      etl: 1Gi
      griffon: 1Gi
      chronos: 1Gi
    data:
      exported: 50Gi
      extracted: 50Gi
      import: 10Gi
      report: 10Gi

  • NFS vs. Longhorn:

    • With NFS, the total available storage is shared across all PVCs, and the individual PVC size is not enforced. Any PVC can use up the full NFS server space.
    • With Longhorn, each PVC is strictly limited to its defined size. You must ensure the sizes are sufficient for your workload.

  • Production Note: For HA production environments, review the Longhorn, NFSv4, and scenario-specific guidance in Exivity Kubernetes best practices.

7. Observability & Monitoring (Kubernetes)​

For comprehensive monitoring, dashboards, and alerting setup, see the dedicated Observability & Monitoring guide.

Troubleshooting & Support​

  • If you encounter issues with NFS or storage, check the pod logs and ensure your NFS server supports NFSv4 and RWX.
  • For further help, contact Exivity support.